前兩天，你接下了這個爛攤子，用盡一切手段撐過了薪資系統危機，CEO Steve 在走廊上拍逆肩膀說「幹得好」，你累到連笑都懶。

但今天早上的站會，讓你發現了一個更可怕的事實。

場景：「我很忙」背後的黑洞

「Phoenix 專案為什麼一直延？」你問。

「我很忙的，」前端工程師說：「昨天 PM 丟了三個緊急需求，今天早上設計又改 UI。」

「我也是，」後端 Lead 接話：「光是處理線上問題就吃掉一半時間，還有那個資料庫效能優化……」

「測試環境掛了兩次，」QA 說：「我得先修環境才能跑測試。」

你打開 Jira，Phoenix 專案板上只有 23 張票，其中 15 張已經 In Progress 超過兩週，沒有新增的 ticket、沒有更新的 comment、沒有進度圖可以看到。

你打開 GitLab，上週有 47 個 commit，但沒有一個 commit message 提到 Phoenix。

你問：「那你們都在忙什麼？」

沉默。

前端工程師翻了翻 Slack：「呃……行銷部要我幫忙拉上個月的用戶留存數據，財務要學報表，還有那個……對，CEO 秘書說要做一個內部活動報名系統。」

後端 Lead 打開 Email：「資安要我改 API 的權限邏輯，HR 系統要加一個欄位，還有三個線上 bug 是客戶直接電話來的。」

你突然懂了。

這個團隊沒有 backlog。

所有工作都是「走廊喊話」、Email 裡一句「幫個忙」、Slack 私訊「順手改一下」插進來的。

你根本不知道大家的時間被什麼吃掉。

兩難：加人？還是先照鏡子？

CEO Steve 傳訊息來：「Phoenix 還要多久？要不要我批幾個 headcount 給你？」

你盯著螢幕，腦中浮現兩條路：

如果是你，現在就要做決定。你選哪個？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：為什麼「看不見」比「做不完」更可怕

正確答案是 B。

聽起來很反直覺，對吧？大家都說「忙死了」，為什麼不多找人？

因為 Fred Brooks 在 1975 年就告訴我們了：將人力投入到已經延誤的專案中，只會讓它更慢（《人月神話》）。

原因很簡單：

• 新人要 onboard（老人時間 -20%）
• 溝通成本以 $n^2$ 呈指數增長（5 個人有 10 條溝通線，10 個人則有 45 條）
• 如果連「現在在做什麼」都不知道，新人只會變成另一個「走廊喊話的接收端」

真正的問題不是人不夠，而是你看不見工作。

《鳳凰專案》裡，Gene Kim 把 IT 的工作分成四種類型：

1. 業務專案（Business Projects）：能直接帶來收入或策略價值的，像 Phoenix
2. 內部專案（Internal Projects）：基礎建設、自動化、技術債償還
3. 變更（Changes）：配置調整、權限開通、例行維護
4. 計畫外工作（Unplanned Work）：線上 bug、緊急救火、「幫個忙」

在你的團隊裡，只有第一種在 Jira 上。其他三種全是隱形的。

• 行銷要的數據拉取？計畫外工作。
• 資安要改 API？變更。
• 測試環境修復？內部專案。
• CEO 秘書的報名系統？……根本不該是你做的事。

如果看不見，就不可能管理產能。

如果不管理產能，加再多人也只是讓更多人一起溺水。

如果你有 AI Agent：讓隱形工作現形

問題是，要求大家「把所有工作都建 ticket」會被罵死。

工程師的直覺反應：「我光是做事就來不及了，還要花時間填表單？」

這時候，AI Agent 可以幫你做一件事：自動把隱形工作變為可視化。與其要求大家填 ticket，不如讓 Agent 去它們藏身的地方把它們挖出來：

graph LR
    A[Slack 訊息] --> D[Agent 彙整]
    B[Email] --> D
    C[Git commit] --> D
    D --> E[自動分類:<br/>業務/內部/變更/計畫外]
    E --> F[每週產生「實際工作清單」]
    F --> G[團隊 review meeting]

Agent 做的事其實很單純：

1. 從 Slack 抓「能不能幫我……」、「急件」、「麻煩」這類關鍵字
2. 從 Email 抓「會議邀請」、「需要你確認」、「可以協助嗎」
3. 從 Git commit 抓「fix」、「hotfix」、「urgent」、「workaround」
4. 用 LLM 把這些「隱形工作」整合成卡片，貼到一個「實際發生了什麼」看板

這就是 2026 年做法：先翻開所有工作，讓大家看見「我們的時間到底去哪了」；再用 Agent 自動彙整那些散落在 Slack、Email 裡的隱形請求，產生一份「實際工作清單」。當你發現計畫外工作佔了一半以上，你就知道該開始說「不」了。

• 行銷要的數據拉取？「這週我們沒有產能，請走正式 ticket 流程排隊。」
• CEO 秘書的報名系統？「這不是我們的範疇，建議用現成的 Google 表單或外部服務。」
• 測試環境第三次掛掉？「我們會排進 backlog 做根本性修復，而不是每次都手動救火。」

說「不」很痛。但如果不說，你永遠在救火，Phoenix 永遠做不完。

現場推演：那份「實際工作清單」的震撼教育

來看一個常見的場景（綜合改編，數字為示意）：

想像一個 8 人的資料團隊，負責數據分析與報表工具維護。Jira 上永遠只有 10 張票，但每個人週報都寫「本週工作滿載」。

主管受不了，請一位資深工程師寫了前面那個 Agent，從 Slack、Email、Git commit 抓出所有「隱形工作」，自動分類成業務專案、內部專案、變更、計畫外工作，每週產生一份「實際工作清單」。

三個月後，統計結果讓所有人傻眼：

• 47% 的工作時間花在「計畫外的資料拉取請求」（行銷、財務、產品都在要數據）
• 23% 花在「非標準化的環境修復」（測試環境、staging 環境每週掛一次）
• 只有 30% 的時間在做「Jira 上有的業務專案」

更驚人的是，那 47% 的資料拉取請求，有 八成是重複性需求：「上週銷售前十名」、「本月新用戶來源分佈」、「各產品線轉換率」——這些根本該做成自助式儀表板，而不是每次都手動 SQL 拉一次。

主管拿著這份清單去找 CEO：「我們不是需要更多人，我們需要停止接這些不該做的事。」

兩週後，那些「幫忙拉數據」的請求被導向一個新建的 BI self-service portal，測試環境修復排進了內部專案 backlog，配了專人處理。

隱形工作現形後，團隊的有效產能直接提升 40%。

今日金句

「最大的敵人不是工作太多，而是工作不可見。看不見的敵人，你連打都打不到。」

留給你的問題

如果現在要你列出團隊這週所有的工作，你列得出來嗎？

如果答案是「不行」，那你就知道為什麽 Phoenix 一直延了。

明天，我們會遇到一個更難的角色：Brent。

那個「什麼都會、什麼都要他」的人。你以為他是救星，但其實他是你最大的瓶頸。

Day 4 見。